In many current wireless communication systems, the radio interface is divided into three separate protocol layers as illustrated in FIG. 1. This type of interface is utilized for example, in a third generation partnership project (3GPP) Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access (UTRA) system. As shown in a wireless transmit/receive unit (WTRU) 5, the protocol layers are a physical layer (L1) 15, a data link layer (L2) 7 and a network layer (L3). The network layer includes a radio resource control unit (RRC) 9. The data link layer 7 comprises a radio link control (RLC) sub-layer 11, a media access control (MAC) sub-layer 13, a packet data convergence protocol (PDCP) layer 6 and a broadcast multicast control (BMC) layer 8.
Some of the physical signaling channels between layers are also labeled. For example, a logical channel 12 is a data transport mechanism between the RLC layer 11 and the MAC layer 13. The logical channel 12 defines the type of data transferred between the two protocol layers. A transport channel 14 is the data transport mechanism between the MAC layer 13 and the physical layer 15. It defines how, and with what characteristics, the data is transferred between the two layers 13, 15. A physical channel 16 is the data transport mechanism sent over the air interface 1 between the physical layer 15 of the WTRU 5 and a peer physical layer 25 in a Node B 17, and defines the physical characteristics of the radio channel.
The Node B 17 has matching protocol peer layers which communicate with their peer layers in the WTRU 5. For example, the Node B 17 has a peer physical layer 25, a peer MAC layer 23, a peer RLC layer 21 and a peer RRC unit 19.
In operation, data is received in the WTRU 5 over the physical channel 16. The physical layer 15 receives the data and forwards transport blocks (TBs) from the physical layer 15 to the MAC layer 13. The TBs are processed by the MAC layer 13 and then by the RLC layer 11 for ultimate processing by the RRC layer 9.
Each layer has it own unique needs for buffering the data. For example, the RLC layer 11 requires reception buffers to support the acknowledged mode (AM) for requesting retransmission of missing blocks and re-sequencing out-of-sequence blocks. The MAC layer 13 also requires buffers for reordering out-of-sequence blocks.
As understood by those of skill in the art, an RLC protocol data unit (PDU) is typically referred to as an acknowledged mode data protocol data unit (AMD PDU) in the context of the AM. In the foregoing description, the terminology RLC PDU is intended to include both RLC PDUs and AMD PDUs, and they may be referred to interchangeably for the purpose of the application.
An example of the use of buffers in the MAC layer 13 for hybrid automatic repeat request (H-ARQ) processing for a WTRU 5 will be described with reference to FIG. 2. Transport block sets (TBS) 24 are utilized to transport data packets. Each TBS has a unique transmission sequence number (TSN). For example, the TBSs of FIG. 2 are each uniquely numbered TSN-24.1 through TSN-24.N and are input to the H-ARQ entity 26.
Due to the nature of the H-ARQ process, the TBSs may be received out-of-sequence or may even be missing. Therefore, TBS TSN-24.3, (which was sent third), arrives before TBS TSN-24.2 (which was sent second); and TBS TSN-24.4 is missing. Based upon the TSNs, the H-ARQ entity 26 detects out-of-sequence and missing TBSs and requests retransmission of the missing TBS. The output of the H-ARQ entity 26 goes to a reordering queue 27, which assigns the TBSs to reordering buffers 28A-28D based upon their priority. The TBSs are reordered and presented to a de-assembly unit 29 which dissembles the TBSs into one or more RLC PDUs, which are then forwarded for further processing by the RLC layer 11. In the RLC layer 11, RLC reception buffers are utilized to re-sequence any RLC PDUs that are not in sequence.
Referring to FIG. 3, an example of the use of buffers by AM entities 30 within the RLC layer 11 is shown. Starting at the bottom of FIG. 3, incoming data 31 from the MAC layer 13 is applied to the first several stages of the RLC layer 11. The incoming data 31 is demultiplexed in the demultiplexer 33 and routed by the router 35 to the deciphering unit 37 where the RLC PDUs are deciphered, (if ciphering is configured).
The data is then sent to the RLC reception buffers and data retransmission unit 39 for transmission management. The data retransmission unit looks at the sequence numbers (SNs) which are attached to the header of each RLC PDU as the RLC PDUs are generated. If one or more RLC PDUs are missing, the data retransmission unit utilizes an error handling routine to send an RLC status report and request that the appropriate RLC PDU(s) be retransmitted. If all the SNs were correctly received, the error handling routine signals a successful transmission.
Once a successful transmission of RLC PDUs has been received, header information is removed and any piggyback information is extracted by a post buffer entity 43. A reassembly entity 45 then reassembles the RLC PDUs into RLC service data units (SDUs). Each RLC PDU waits at the reception buffer 39 until all RLC PDUs of the RLC SDU are completely received. Once all RLC PDUs are received and are correct, the data is passed up to the acknowledge mode—subsystem application part (AM-SAP) 47 and eventually passed to the non-access stratum (NAS) 49, which are the upper layers of the WTRU protocol stack.
As data flows from the Node B 17 to the WTRU 5, there is a transmission-window mechanism to control the transmission rate of the RLC PDUs. The sender only allows a certain number of PDUs to be transmitted between the peer RLC entities. This number is always less than the RLC transmission window size and is known by both RLC entities.
The RLC transmission window size can be adjusted through control signaling. At any instant, reconfiguration of the RLC transmission window size by the RLC sender should take into account the total buffer size allocated for both the MAC reordering buffers and the RLC reordering buffers.
According to the current 3GPP standard for High Speed Downlink Packet Access (HSDPA), the WTRU will signal the UTRAN to configure transmission window sizes in order to prevent data loss. There are several factors which are considered to generate an appropriate signal for the UTRAN. If the WTRU does not employ high speed downlink shared channel (HS-DSCH) services, the total buffer size is defined as the maximum total buffer size across all RLC AM entities supported by the WTRU. For HS-DSCH, which occurs only on the downlink, the total buffer size is defined as the maximum total buffer size across all MAC reordering entities and all RLC AM entities supported by the WTRU. Table 1 is a summary of the elements that are taken into account when determining the maximum buffer size.
TABLE 1MAXIMUM BUFFER SIZEWITHOUT HS-DSCHWITH HS-DSCHMAX TOTAL BUFFERMAX TOTAL BUFFER SIZE ACROSSSIZE ACROSSALL RLC AM ENTITIES +ALL RLC AM ENTITIESALL MAC REORDERING BUFFERS
Equation 1 is utilized to derive a maximum buffer size of a WTRU:
                                                        ∑                              i                =                1                                            #                ⁢                                                                  ⁢                RLC_AM                ⁢                _entities                                      ⁢                          Transmission_window              ⁢                              _size                i                            *                              (                                                      UL_RLC                    ⁢                    _PDU                    ⁢                                          -                                        ⁢                                          size                      i                                                        -                                      RLC_Header                    ⁢                    _size                                                  )                                              +                                    ∑                              i                =                1                                            #                ⁢                                                                  ⁢                RLC_AM                ⁢                _entities                                      ⁢                          Receiving_window              ⁢                              _size                i                            *                              (                                                      DL_RLC                    ⁢                    _PDU                    ⁢                                          -                                        ⁢                                          size                      i                                                        -                                      RLC_Header                    ⁢                    _size                                                  )                                              +                                    ∑                              j                =                1                                                              #                  ⁢                                                                          ⁢                  MAC                                -                                  hs_reodering                  ⁢                  _entities                                                      ⁢                          MAC_reodering              ⁢                                                          ⁢              _entity              ⁢                                                          ⁢              _buffer              ⁢                                                          ⁢                              _size                j                                                    ⁢                                  ≤                  Total_buffer          ⁢          _size                                    Equation        ⁢                                  ⁢                  (          1          )                    where Transmission_window_size is the size of a particular entity (i's) transmission window size; UL_RLC_PDU_sizei is the size of a particular entity (i's) UL RLC PDU buffer; RLC_Header_size is the size of a particular entity (i's) RLC header; Receiving_window_size is the size of a particular entity (i's) reception transmission window size; DL_RLC_PDU_sizei is the size of a particular entity (i's) DL RLC PDU buffer; RLC_Header_size is the size of a particular entity (i's) RLC header; and MAC_reordering_entity_buffer_size is the size of a particular entity (j's) MAC reordering buffer.
For example, if a WTRU has two UL RLC PDU buffers, two DL RLC PDU buffers and three MAC reordering buffers, and all of the buffers have a fixed size of 5 kilobytes (kb) and a fixed header size of 1 kb, from Equation 1 it can be determined that the total buffer size be at least 31 kilobytes.
In the context of RLC transmission, the buffer (or memory) installed within a WTRU dictates the RLC window size. There is a tradeoff between memory requirements and performance. In general, a larger memory permits a large window size which leads to more robust performance, but greatly increases the manufacturing cost of the WTRU. A smaller memory can only support a reduced window size. If the window size is too small, there is a greater tendency for the transmitting side to be forced to suspend new transmissions while waiting for errors to be corrected. This both reduces the effective data rate and increases the latency of the overall transaction.
Additionally, there are often separate dedicated memories with specific functions that are dedicated to different layers. This is a very inefficient utilization of hardware.
It would be desirable to have an efficient method for allocating memory for different functions while still maintaining high effective data rates.